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AMENDMENTS TO THE SPECIFICATION 

Please replace paragraph [0004] with the following: 

[0004] Accordingly, the present invention is directed to systems and methods for 

providing multicast capabilities for communication systems. In an exemplary embodiment using 
for example CDMA-2000, the communication systems and methods may include wireless 
communications and internet protocol (IP). The communication system may include one or 
more content servers (CSs) coupled to an IP network. The content servers may provide a 
communication multicast on the same IP multicast address. The IP network may be coupled to 
one or more packet data serving nodes (PDSNs) that may receive IP multicast routing protocols 
and IP multicast packets from the IP network. The one or more PDSNs may be coupled to a 
radio-to-packet network (RP network) that may include IP. One or more base stations (BSs) 
that may include packet control functions (PCFs) may be coupled to the RP network . One or 
more mobile stations (MSs) may be coupled to the BS/PCF using, for example, interim standard 
2000 (IS-2000). The PDSN to MS communications may use, for example, protocols IGMP 
(IPv4) and/or MLD (IPv6) for control signaling of the IP multicasting. These protocols may be 
augmented by Multichannel Flow Treatment Protocol (MCFTP). 

Please replace paragraph [0006] with the following: 

[0006] In one embodiment, a PDSN may generate a Flow_Code and MCS_Ref per 

multicast information flow based on a request by one or more MSs to join a multicast from a 
particular CS. The Flow_Code may be globally unique to identify a particular multicast from a 
particular content server. The MCS_Ref may be locally unique to a group of PSDNs and may 
be afe-mapped to a particular Flow_Code via, for example, a binding procedure. The PDSN 
may receive filters from the MS using, for example MCFTP, that may be used to provide packet 
classification for mapping the multicast information flows to an MCS_Ref . The PDSN may 
provide the Flow_Code and MCS_Ref binding to the BS/PCF where it may be stored and send 
the required MCS_Ref through the BS/PCF to the MS that meets the requested multicast 
information flow. The BS/PCF may generate and allocate Radio_Params mapped to the 
MCS.Ref^ which are ie-needed by an MS to tune into the multicast session in the case of a 
radio broadcast flow treatment of the multicast information. The BS/PCF may send the 
MCS_Ref - Radio_Params mapping to the MS . The and tho MS uses this mapping information 
to tune into the requested multicasting session being broadcast by the BS/PCF. 



2 



C&B Ref. No. 4740-027 
Client Ref. No. P15164-US 
Application Serial No.09/975,760 

Please replace paragraph [0007] with the following: 

[0007] In operation, a mobile station may establish multicast communication that 

includes information from one or more of the content servers. The mobile station may tune into 
more than one multicast at a time. In various embodiments the MCFTP protocol may be used by 
the MS to inform the system whether a shared broadcast service or a dedicated ordinary 
communication channel should be used to transmit the multicast information. In the case when 
a radio broadcast is used, numerous MSs can receive the multicast information simultaneously. 
However, if a BS/PCF does not have a distinct radio broadcast channel or the MS is not capable 
of receiving information on the distinct radio broadcast channel, an ordinary BS to MS 
transmission channel may be used. The network may play a role in determining whether the 
channel established is a broadcast channel or a dedicated channel. For example, the network 
may turn an existing multicast flow provided on a dedicated channel to a flow bem§-provided on 
a broadcast channel, i.e., a dedicated channel into a broadcast channel. Further, the network 
may provide the multicast flow on a broadcast channel even though a MS requests a dedicated 
channel, and the network may instruct the MS to use the broadcast channel. Efficiency may 
play a role in determining network assignment of a broadcast channel or dedicated channel for 
the multicast flow. If, for example, only one MS has requested a flow, the network might dictate 
a dedicated channel so that the system uses the power control feature found with a dedicated 
channel. If more then one MSs are requesting to become members of a multicast flow through 
one BS/PCF, then the network ma y use bave-a threshold that is ucod to determine whether or 
not to use one broadcast channel or multiple dedicated channels. Further, as previously 
indicated, various embodiments may have signaling for establishing a multicast session that 
may include a number of identifiers^ such as the CS address, IP multicast address, a unique 
flow identifier that identifies a multicast flow to identify information flowing from the same 
multicast through different PDSNs (Flow_Code), a multicast identifier unique to a particular 
multicast service (MCS_Ref), and a radio parameter identifier (Radio_Params) that may include 
radio parameters used for setting a MS to receive a particular multicast. Using these various 
identifiers the system provides a scalable approach to establishing numerous multicast service 
instances with multicast information flowing from one or more content servers to one or more 
mobile stations. Various exemplary signaling embodiments are provided herein to indicate how 
multicasting service may occur according to the present invention. 
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Please replace paragraph [0008] with the following: 

[0008] In one embodiment the mobile station may instruct the system that it wishes to 

listen to a particular multicast from a particular content server on an ordinary communication 
channel. In this case the signaling may include, for example, an Internet Group Management 
Protocol (IGMP) status report and a MCFTP pattern update. In another embodiment, the mobile 
station may instruct the system that it wishes to listen to a particular multicast from a particular 
content server on a broadcast channel without having been a previous subscriber to the 
multicast. In this case the signaling may include, for example, an IGMP status report, a 
MCFTP pattern update, and a bind statement including Flow_Code and MCS_Ref identifiers. In 
even another embodiment, a mobile station instructs the system that it wishes to listen to a 
particular multicast from a particular content server and a particular PDSN over a broadcast 
channel, where the multicast has already been subscribed to by another MS. In this case, the 
signaling may include, for example, an IGMP status report, an MCFTP pattern update including 
a Broadcast channel request, and an MCFTP message that includes a map flow to an 
MCS_Ref. In still another embodiment, a mobile station instructs the system that it wishes to 
couple to a particular PDSN and continuejo listen to a particular multicast from a particular 
content server on a broadcast channel, though another MS has already been a subscriber to the 
same multicast from the same content server through a different PDSN. In this case the 
signaling may include, for example, an IGMP status report, an MCFTP pattern update including 
a Broadcast flow treatment request, a bind statement including Flow_Code and MCS_Ref2 
identifiers, a bind exist statement including MCS_Ref 1 , and an MCFTP message that includes a 
map flow to an MCS_Ref 1 . In yet another embodiment, the MS moves from one BS/PCF cell 
to another BS/PCF cell^ and the system coordinates the continuation of an existing multicast 
flow with the MS. In this case A the signaling may include, for example, a new packet zone 
identifier (PZID), a new RP link message, an unbind statement including Flow_Code and 
MCS_Ref identifiers, and a bind statement including Flow_Code and MCS_Ref identifiers. 

Please replace paragraph [0012] with the following: 

[0012] The signaling between various system devices is carried out using a number of 

protocols to enable an IP multicast service. Typically at least two protocols are needed. First, 
an IP host-based protocol may be provided to allow a receiver device to notify a local router(s) 
that it wishes to join a particular multicast service group and request the initiation of the data 
flow from all sender(s) within the scope of the multicast service group. For oxamplo. Exemplary 
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protocols include Internet Engineering Task Force (IETF) based host-to-router protocols^ such 
as internet group management protocol (IGMP) used with Internet protocol version 4 (IPv4), and 
multicast listener discovery protocol (MLD) used with Internet protocol version 6 (IPv6). 
Second, an IP router-based protocol may be provided to allow a multicast source to send 
multicast datagrams to one or more multicast group addresses and any routers with multicast 
group members (e.g., receiving devices) on their local networks to communicate with other 
routers to ensure that all datagrams sent to the multicast group address are forwarded to all 
receivers within the intended scope of the multicast service group. An example of such a 
routing protocol is multicast open shortest path first (MOSPF) which may be an open shortest 
path first (OSPF) that is modified to include multicast extensions. Further, the multichannel flow 
treatment protocol (MCFTP) defined by TSG-P (subgroup within the Third Generation 
Partnership Project 2, 3GPP2) may be used for the purpose of identifying IP flows and defining 
their treatment. 

Please replace paragraph [0013] with the following: 

[001 3] The 3GPP2 document 3GPP2 P.S0001 -B, Version 1 .0.0, dated September 1 7, 

2001 , and entitled 'Wireless IP Network Standard," includes an Annex F that provides details on 
MCFTP. This document is incorporated herein by reference in its entirety. While the 3GPP2 
document should be referred to for detailed inquiry, MCFTP in general supports the signaling of 
3GPP2 packet filters, header stripping/generation and header removal information in the packet 
data network. Additionally, MCFTP might be used to signal channel treatment for an auxiliary 
service instance on which no PPP (Point-to-Point Protocol) control signaling may be carried. 
Further, channel treatment such as PPP compression or encryption might be indicated via 
MCFTP. 

Please replace paragraph [0015] with the following: 

[001 5] Referring now to FIG. 1 , an exemplary communication system including IP 

multicast services according to the present invention is provided. As illustrated, the 
communication system may include one or more content servers (CSs), CS1 110 and CS2 115, 
coupled to an IP network 120. Each of the content servers may have an assigned address, for 
example 135.23.34.56 for CS1 1 10 and 28.25.33.79 for CS2 115. The IP network 120 may be 
coupled to one or more packet data serving nodes (PDSNs), for example PDSN1 125 and 
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PSDN2 130. The PSDNs may be, for example, routers. The multicast packets may be routed 
from the CSs to the PDSNs through routers in the IP network 120 supported by, for example, IP 
multicast routing protocols. These IP multicast routing protocols used between the CSs and 
PDSN are in one embodiment preferably standard IP multicast routing protocols such as 
MOSPF, without any other interface. As indicated, the content servers may provide respective 
communication multicasts that are transmitted to the same IP multicast address, e.g., 224.1 .2.5. 
PDSN1 125 and PDSN2 130 may be coupled to a radio-to-packet network 135 (RP network 
(IP)) that may include IP. The RP network (IP) 135 may be coupled to one or more base 
stations that include packet control functions (PCFs), for example, BS/PCF1 145 and BS/PCF2 
150. One or more mobile stations (MSs), e.g., MS1 140 and MS2 155, may be coupled to the 
BS/PCFs using, for example, interim standard 2000 (IS-2000). As indicated in FIG. 1 , the 
PDSN to MS communications may use, for example, protocols IGMP (IPv4) and/or MLD (IPv6) 
for control signaling of the IP multicasting. These protocols may be augmented by MCFTP. 
Although the system of FIG. 1 illustrates only two CSs, two PDSNs, two BS/PCFs, and two 
MSs, the system may be scaled to have any number of these devices. In fact, from a practical 
perspective, it is likely that the system would have many more MSs coupled to it at any given 
instant in time. 

Please replace paragraph [0016] with the following: 

[0016] In operation, the system uses end-to-end IP multicast. IP multicast packets are 

directly routed to the PDSNs, PDSN1 125 and PDSN2 130, and IP multicast mechanisms are 
used with the PDSNs being the first hop router seen by the mobile stations, MS1 140 and MS2 
155 . The MS requests receipt of an IP multicast and the system establishes the routing to send 
the correct IP multicast datagrams to the MS. In the example provided in FIG. 1 both content 
servers, CS1 1 10 and CS2 115, "send" multicast packets to the same IP multicast address 
(224.1.2.5). As such, there are two different IP multicast flows active in the network which may 
be designated by the MSs for receipt, multicast flow 135.23.34.56, 224.1 .2.5 from CS1 1J0 and 
multicast flow 28.25.33.79, 224.1 .2.5 from CS2 115. By having more content servers in the 
network, there would be more multicast flows that are possible through a given multicast 
address. Although a MS may typically request a single multicast flow at a time, a MS could 
request simultaneous reception of more than one multicasts or all multicasts sent to a particular 
multicast address by, for example, simply requesting receipt of the multicast address (e.g., 
224.1 .2.5). Any valid Ipv4 or Ipv6 multicast addresses may be used by the CSs. The multicast 
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addresses do not have to be previously known by the MS, but they can be. For example, the 
multicast address may be stored in the MS memory or IP application (e.g., web browser). In 
one variation, the multicast address may be sent in real time with, for example, an 
announcement using protocols such as session internet protocol (SIP), real time transport 
protocol (RTSP), etc. 

Please replace paragraph [0017] with the following: 

[0017] The RP network (IP) 1 35 has in this example a 2-2 configuration and as such, 

any BS/PCF can connect to any PDSN. In other words, a BS/PCF having multiple MSs coupled 
to it may have some MSs coupled to PDSN1 125 and some MSs coupled to PDSN2 130 . 
Further, a MS can change its serving BS/PCF without changing PDSNs. For example, MS1 140 
may first be coupled to PDSN1 125 through the BS/PCF1 145 while traveling in the BS/PCF1 
145 cell then be coupled to PDSN1 125 through the BS/PCF2 150 by moving into the BS/PCF2 
150 cell. The MS;s request to join a multicast group and to receive multicast data transmission 
may be set up and managed by using control signaling such as IETF protocols IGMP (Ipv4) 
and/or MLD (Ipv6) along with MCFTP. Although, the MCFTP may include various modifications. 
Further, the IS-2000 air interface between the BS/PCFs and MSs may be modified to include a 
radio broadcast capability to efficiently utilize the radio channels available to the BS/PCFs. By 
introducing a broadcast feature to the MCFTP, more than one MS may listen to the same IP 
multicast using one transceiver of a respective BS/PCF. The RP network 135 interface may also 
require some modification as well. For example, the multicast flow may be associated with a 
broadcast channel rather than a dedicated channel. 

Please replace paragraph [0022] with the following: 

[0022] As illustrated above, the three identifiers, Flow_Code, MCS_Ref, and 

Radio_Params, and other identifiers (e.g., CS address and multicast address) may be combined 
to provide flexible and efficient multicast communications sessions that may be scaled without 
causing excessive system traffic, to limit the information or knowledge required by the BS/PCF 
204, and resolve handoff situations. Integrated with the use of one or more radio broadcast 
channel(s) included in the BS/PCFs, the present invention will enable efficient multicast 
communications that take into consideration the limited bandwidth of the air interface included in 
the last hop of the system including the PDSNs, BS/PCFs, and MSs. As constructed according 
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to the present inventionO and as perceived by the mobile station user A the multicast service 
and system may provide an "always on" type of service similar to TV broadcasting service. 

Please replace paragraph [0024] with the following: 

[0024] Referring now to FIG. 3, an exemplary signal flow is illustrated for an 

embodiment in which MS1 140 establishes a multicast communication session with CS2 JM5 
using a dedicated radio channel. According to the present invention, a MS may request a 
particular IP multicast flow to be mapped to a dedicated radio channel (i.e., similar to a "normal" 
service instance) rather than to a broadcast channel. This request could be the result of various 
system needs, for example, internal limitations in the MS, application specific needs, the current 
Radio Access Network (RAN) (i.e., the BS/PCF) may not support the broadcast capability, etc. 
In any case, a multicast communication session may be established between CS2 115 and MS1 
140 on a dedicated mobile radio channel using the exemplary signaling steps illustrated in FIG. 
3. 

Please replace paragraph [0025] with the following: 

[0025] First, MS1 140 finds out that an IP Multicast flow is sent from CS2 1 1 5 (address 

28.25.33.79) to the IP multicast group (address 224.1 .2.5), e.g. through some other protocol 
such as SIP, Hypertext Transfer Protocol (http), etc. For example, a user might activate a 
hyperlink to connect to a streaming audio session. In this case, in step 301 , the MS1 140 is 
sent an announcement message indicating that a multicast communication session is active. 
This announcement, Announcement (224.1.2.5, 28.25.33.79), includes the IP multicast address 
and the content server address for CS2 115. Next, at step 302 Jhe MS1 140 decides to listen 
to this flow, but does not want to listen to the broadcast capabilities, due to e.g. lack of 
capability/resources. Thus, MS1 140 and BS/PCF1 145 establish a new service instance for 
this IP multicast flow. However, in one variation of the invention, a new service instance might 
not be established if there is an existing broadcast of an IP multicast flow for the same IP 
multicast that could be used. Then, at step 303, MS1 140 sends an IGMP Status Report 
(224.1 .2.5) message to PDSN1 125 that includes the multicast address to join the multicast 
group. Next, at step 304, PDSN1 125 will interact with other routers in the IP 120 to become a 
part of the multicast tree for the IP multicast occurring on address 224.1 .2.5 via various IP 
multicast routing protocols. Then, at step 305, the MS1 140 sends an MCFTP pattern update 
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(map traffic source 28.25.33.79 dest 224.1.2.5 to SR_ID=X) request to PDSN1 125 to create a 
mapping from the IP multicast flow to the newly created service instance (X). An SRJD is 
typically used for normal services (non multicast/broadcast) to differentiate different "channels" 
that are allocated to various MSs. An SRJD identifies a service instance that is a logical 
connection typically associated with a channel over the air interface allocated for a MS. Then at 
step 306, an IP multicast flow session is established and IP multicast data flows from CS2 115 
over the new service instance through IP 120, PDSN1 125, RP network 135 (not shown), and 
BS/PCF1 145 to MS1 140. 

Please replace paragraph [0027] with the following: 

[0027] Referring now to FIG. 4, an exemplary signal flow is provided for one 

embodiment in which MS1 140 establishes a multicast communication session with CS1 HQ 
using a broadcast channel, without having previously been a subscriber to the requested 
multicast communication session. First, at step 401 , MS1 140 finds out that an IP multicast flow 
is sent from CS1 110 (1 35.23.34.56) to the IP multicast group (address 224.1 .2.5), via an 
announcement message, Announcement (224.1.2.5 source 135.23.34.56). In a variation, MS1 
140 could find out about the IP multicast through some other protocol such as SIP, http, etc. 
Next, at step 402, MS1 140 sends an IGMP message including the multicast address, IGMP 
Status Report (224.1 .2.5), to PDSN1 125 to request joining the multicast group. Then, at step 
403, if not already receiving the requested IP multicast flow, the PDSN1 125 may interact with 
other routers to become a part of the multicast tree for the requested IP multicast flow. Next, at 
step 404, MS1 140 may send a MCFTP pattern update request, MCFTP Pattern Update (traffic 
source 135.23.34.45 dest 224.1 .2.5, flow treatment BROADCAST), indicating that it wishes to 
receive the IP multicast flow over a broadcast service channel if it is possible for the RAN 
system to provide a radio broadcast service for the IP multicast. If it is possible, then at step 
405, the request for the broadcasted IP multicast session is authorized by PDSN1 125. 
Otherwise the IP multicast session may be provided to MS1 140 over an ordinary channel (e.g., 
see signaling in FIG. 3). In this case it is authorized, so at step 406 PDSN1 125 generates or 
creates a globally unique Flow_Code from the filter specification received in the MCFTP update. 
For example, the Flow_Code may include the source address, destination address, destination 
port, etc. from the filter which is then encoded with an algorithm to produce a unique multicast 
flow specific bit string. This string may be sent by the PDSN 202 and matched in the BS/PCF 
204 to a mapped bit string. This Flow_Code may be created using a standardized algorithm 
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and may be the same regardless of which PDSN that generated it. PDSN1 125 may also 
generate a new MCS„Ref. Then PDSN1 125 may send a request to BS/PCF1 145 for a binding 
to be created between the Flow_Code and the MCS_Ref, Bind (Flow_Code, MCS_Ref). Then, 
at step 407, if BS/PCF1 145 can not find the FIow_Code in its tables and determines that no 
radio broadcast channel has been established for this IP multicast flow, BS/PCF1 145 may 
perform some admission control to determine if there is sufficient capacity for this request to be 
granted. If so, then at step 408 BS/PCF1 145 may store the binding for the Flow_Code, 
MCS_Ref for future use and gives a positive OK response back to PDSN1 125. Next, at step 
409, PDSN1 125 may use an MCFTP message in response to the Pattern Update Request, 
MCFTP (map flow to MCS_Ref), indicating the MCS_Ref to be used by MS1 140 for the IP 
multicast flow. In one variation, this message may be a Pattern Update Request message. In 
either case, MS1 140 may start "listening" for a MCS_Ref to Radio_Params mapping using the 
MCS_Ref provided by PDSN1 . Then, at step 410, the BS/PCF1 145 and the MS1 140 
cooperate to establish the air interface. For example, the BS/PCF1 145 takes action to 
establish the broadcast "channel". This may be triggered by, for example, establishing the 
binding of Flow_Code and MCS_Ref discussed above or by an arriving IP multicast session 
data flow shown in step 41 1 . The BS/PCF1 145 would establish a Radio_Params identifier and 
map it to the MCS_Ref . The procedure may include establishing QoS parameters for the 
channel. BS/PCF1 145 may, for example, now start to transmit/broadcast the MCS_Ref- 
>Radio_Params binding over the air interface. Then, the MS1 140 would detect the MCS_Ref 
to Radio.Params mapping and tune its receiver to the defined channel to start receiving the 
incoming IP multicast data. Or, the MS1 140 may request the MCS_Ref->Radio_Params 
binding information from the network. As such, in step 41 1 , user data (i.e., the IP multicast 
communication session data) can now flow from CS1 1 10 to MS1 140 over the newly 
established broadcast channel. 

Please replace paragraph [0028] with the following: 

[0028] Referring now to FIG. 5, an exemplary signal flow is provided for an embodiment 

in which MS2 155 establishes an IP multicast communication session with a CS1 1 10 through 
PDSN1 125 using a broadcast channel, after MS1 140 had already been a subscriber of the 
multicast through PDSN1 125 and BS/PCF1 145 via a broadcast channel. In this case, the 
signal flow is simplified because the multicast had already been routed through PDSN1 125 and 
BS/PCF1 145, and a broadcast channel was already established for the multicast via BS/PCF1 
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145 and MS1 140. First, at step 501 , MS2 155 finds out that an IP multicast flow is sent from 
CS1 1 10 at address 135.23.34.56 to the IP multicast group at address 224.1 .2.5, e.g. through 
an announcement message, Announcement (224.1 .2.5 source 135.23.34.56). In a variation, 
some other protocol such as SIP, http, etc. could be used. In any case, the MS2 155 user, 
being aware of the IP multicast, decides to subscribe to the IP multicast. Thus, at step 502, 
MS2 155 sends an IGMP message, IGMP Status Report (224.1.2.5), to PDSN1 125, requesting 
to join the multicast group. PDSN1 125 is already a part of that IP multicast tree so that the IP 
multicast routing protocols and Flow_Code, MCS_Ref generation and binding are already 
completed. Next, MS2 155 sends a MCFTP pattern update request, MCFTP Pattern Update 
(traffic source 135.23.34.56, dest 224.1.2.5, flow treatment Broadcast), to PDSN1 125 indicating 
that it is to receive the IP multicast flow over a radio broadcast channel, if radio broadcast 
service is possible. Then, at step 504 PDSN1 125 authorizes the broadcast service request. 
However, PDSN1 125 determines that there is already a binding for this IP multicast flow and 
finds the corresponding MCS_Ref Jott-Fof example, by matching the filter specification of the 
request to the list of already known IP multicast flows. In one variation, PDSN1 125 may send 
an indication to the BS/PCF 145 that a new subscriber MS2 155 was added. Next, at step 505, 
PDSN1 125 may send a MCFTP message, MCFTP (map flow to MCS_Ref), to MS2 155 in 
response to the Pattern Update Request, indicating the MCS_Ref to be used for setting up and 
managing the IP multicast flow. In one variation, a Pattern Update Request message could be 
sent from PDSN1 125 to MS2 155 to indicate the MCS_Ref to be used for the IP multicast flow. 
MS1 155 may now use the MCS_Ref to determine the MCS_Ref, Radio_Params mapping to 
use to couple to the IP multicast communication. Then, at step 506, user data for listening to the 
IP multicast session may flow from CS1 1 10 to MS2 155 using the newly established broadcast 
channel. If in this scenario MS2 1 55 were to have connected to a different BS/PCF then MS1 
140, e.g., BS/PCF2 150, using the same PDSN1 125, then the signaling would be similar to that 
found in FIG. 4. 

Please replace paragraph [0029] with the following: 

[0029] Referring now to FIG. 6, an exemplary signal flow for an embodiment in which 

MS2 155 couples to PDSN2 130 and requests to connect with an IP multicast from CS1 1 10 on 
a radio broadcast channel, and MS1 140 has been listening to the same IP multicast flow over 
PDSN1 125 using the same BS/PCF1 145. First, at step 601 , the IP multicast flow (user data) 
from CS1 1 10 is broadcasted to MS1 140. The multicast flow is mapped to MCS_Ref1 . MS1 
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140 is coupled to PDSN1 125. Then, at step 602, MS2 155, which is registered with PDSN2 
130 t finds out via an announcement message, Announcement (224.1.2.5 source 135.23.34.56), 
that an IP Multicast flow is sent from CS1 110 (address 135.23.34.56) to the IP multicast group 
(address 224.1 .2.5). In a variation, MS2 1 55 could find out about the IP multicast from CS1 1 1 0 
through some other protocol, such as SIP, http, etc. Next, at step 603. MS2 155 may send an 
IGMP message, IGMP Status Report (224.1.2.5) to join the IP multicast from CS1 1 10 via 
PDSN2 130. Then, at step 604, PDSN2 130 may interact with other routers to become a part 
of the IP multicast tree for the requested multicast. Next, at step 605, MS2 155 may send a 
MCFTP message request, MCFTP Pattern Update (traffic source 135.23.34.56 dest 224.1 .2.5, 
flow treatment BROADCAST), to PDSN2 130 indicating that MS2 155 is to receive the IP 
multicast flow requested over a broadcast channel if broadcast service is possible. Then, at 
step 606, PDSN2 130 may authorize the request from MS2 155. PDSN2 130 may then create a 
globally unique Flow_Code from the filter specification received in the MCFTP pattern update. 
For example, the Flow_Code may include the source address, destination address, destination 
port, etc. from the filter which is then encoded with an algorithm to produce a unique multicast 
flow specific bit string. This string may be sent by the PDSN 202 and matched in the BS/PCF 
204 to a mapped bit string. This Flow„Code may be created using, for example, a standardized 
algorithm and may be the same regardless of which PDSN generates it. PDSN2 1 30 may also 
generate a new MCS_Ref (MCS_Ref2). Then, at step 607, PDSN2 130 may send a request to 
BS/PCF1 145 for a binding, Bind (Flow_Code, MCS_Ref2), to be created between the 
Flow_Code and MCS_Ref2. However, BS/PCF1 145 looks at its stored list of bindings and 
finds an already existing mapping for that Flow_Code that was created by PDSN1 125 for the IP 
multicast flow to MS1 140. Thus, in step 608 BS/PCF1 145 responds back to the PDSN2 130 
that a binding for that IP multicast already exists, Binding exists (MCS_Ref 1 ). Next, at step 609, 
PDSN2 130 revises its binding for the IP multicast flow to MCS_Ref1 and sends a MCFTP 
message, MCFTP (map flow to MCS_Ref1), (which may be in response to the Pattern Update 
Request message at step 605) indicating the MCS_Ref to be used for the IP multicast flow 
requested is to be MCS_Ref1 . In a variation, the message at step 609 may be, for example, a 
Pattern Update Request. MS2 440155 may now detect the MCS_Ref 1 , Radio_Params 
mapping that may be regularly sent out or broadcasted by BS/PCF1 . MS2 1 55 may then tune 
into the requested IP multicast session using, for example, the same Radio_Params used by 
MS1 140 and start listening for user data. Finally, at step 61 0, user data can flow from CS1 1 1 0 
to MS2 155 over the same broadcast channel as is being used by MS1 140. Of course, MS1 
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140 may chose at some point to stop being a member of the IP multicast from CS1 without 
altering the signaling. Thus, as illustrated by the approach in FIG. 6, if two (or more) MSs are 
connected to two different PDSNs, but to the same BS/PCF, and they both want to receive the 
same IP Multicast flow using the radio broadcast flow, the system is configured for efficiency to 
ensure that only one multicast stream is sent over the air. 

Please replace paragraph [0030] with the following: 

[0030] Referring now to FIG. 7, an exemplary signal flow is illustrated for an 

embodiment in which MS1 140, active in a multicast communication session with CS1 110, 
moves from BS/PCF1 145 to BS/PCF2 150 and may continue the IP multicast session through 
the same PDSN, PDSN1 125. If MS1 140 moves into an area served by BS/PCF2 150, it will 
detect entering a new area through receipt of, for example, a new PZID, system identification 
(SID) or network identification (NID) that is broadcasted. As indicated at step 701 , MS1 
receives a new PZID. This may trigger MS1 140 to listen for a new MCS_Ref -> Radio_Params 
mapping for the IP multicast flow it has been receiving via BS/PCF1 145. If MS1 140 finds a 
new MCS_Ref -> Radio_Params mapping, it will start listening to this new "channel" instead. If 
not, MS1 140 may continue to listen for such a mapping, while the network will adjust to the 
move of MS1 140 from BS/PCF1 145 to BS/PCF2 150. Thus, in step 702, BS/PCF2 150 may 
send, for example, a standard New RP link message to PDSN1 125 , and the change of 
BS/PCFs triggers a "hand-off" of the RP network 135 link from the old BS/PCF BS/PCF1 145 to 
the new[[J] BS/PCF2 150. 

Please replace paragraph [0031] with the following: 

[0031] Next, at step 703, since MS1 140 is no longer connected to BS/PCF1 145, 

PDSN1 445125 sends an unbind message, Unbind (Flow_Code, MCS_Ref 1 ) to BS/PCF1 145. 
In response, BS/PCF1 145 may remove MS1 140 from the list of "listeners" or this specific 
Flow_Code, and may if there are no other mobile stations listening to the flow de-allocate the 
radio resources associated with the multicast flow, terminating the transmission. Then, at step 
704, PDSN1 125 determines that the BS/PCF association of MS1 140 has changed to BS/PCF2 
150 and sends a binding request message, Bind (Flow_Code, MCS_Ref2), to BS/PCF2 150 for 
a binding to be created between the Flow_Code and MCS_Ref2. Next, at step 705, BS/PCF2 
150 will not find the Flow.Code in its binding tables and determines that no "broadcast channel" 
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has been established for this flow. BS/PCF2 150 may then perform some admission control to 
determine if resources exist so that the request from MS1 140 could be granted. BS/PCF2 150 
may then store the binding Flow_Code, MCS_Ref2 for future use. Then if the resources are 
available BS/PCF2 150, at step 706, may send a positive response back to PDSN1 125 
indicating that the IP multicast session may be broadcast to MS1 140. Next, at step 707, 
BS/PCF2 may take action to establish the broadcast "channel", establishing air interface 
procedures with MS1 140. This may be triggered by, for example, the binding indicated above 
in step 704, or by an arriving IP multicast session data flow (see step 708). The procedure may 
include, for example, establishing QoS parameters for the new broadcast channel. BS/PCF2 
150 may, for example, also now start to transmit/broadcast the MCS_Ref2->Radio_Params 
binding over the air interface. Of course, the MS 1 140 may request receipt of the MCS_Ref2- 
>Radio_Params binding from the network. The M SMS1 140 may detect the MCS_Ref2-> 
Radio_Params mapping from the BS/PCF2 150 to tune into the specified Radio_Params to start 
receiving user data. Then, at step 708, user data for the IP multicast session may flow from 
CS1 1 1 0 over a newly established broadcast channel from BS/PCF2 1 50. 
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